[JEWEL-1276] Fix popup focus-stealing in JDialogRenderer#3476
Open
rock3r wants to merge 1 commit intoJetBrains:masterfrom
Open
[JEWEL-1276] Fix popup focus-stealing in JDialogRenderer#3476rock3r wants to merge 1 commit intoJetBrains:masterfrom
rock3r wants to merge 1 commit intoJetBrains:masterfrom
Conversation
Collaborator
DanielSouzaBertoldi
left a comment
DanielSouzaBertoldi
left a comment
There was a problem hiding this comment.
Besides not understanding the MacOS quirk at play here, it works and it's the way JB has been doing for a while now so that's fine by me 😎
...-ui-standalone/src/main/kotlin/org/jetbrains/jewel/intui/standalone/popup/JDialogRenderer.kt
Show resolved
Hide resolved
DejanMilicic
approved these changes
Apr 3, 2026
AlexVanGogen
approved these changes
Apr 13, 2026
...-ui-standalone/src/main/kotlin/org/jetbrains/jewel/intui/standalone/popup/JDialogRenderer.kt
Outdated
Show resolved
Hide resolved
Prevent JDialog-backed popups from stealing key-window status on macOS, which caused the parent window title bar and traffic-light buttons to appear greyed out (inactive). Apply the same focusableWindowState toggle technique used in IntelliJ's AbstractPopup/DialogPopupWrapper: set focusableWindowState=false and isAutoRequestFocus=false synchronously before setVisible(true), then restore focusableWindowState=true via SwingUtilities.invokeLater. This lets the popup show without becoming the macOS key window, while still allowing it to accept focus on explicit user interaction. Also change the AWTEventListener keyboard gate from dialog.isActive to dialog.isVisible, so onKeyEvent/onPreviewKeyEvent callbacks fire without requiring the dialog to be the key window.
rock3r
force-pushed
the
sebp/JEWEL-1276_fix-standalone-popup-focus-stealing
branch
from
27811ae to
15a7b33
Compare
nebojsa-vuksic
approved these changes
Apr 15, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Focusable popups rendered via
JDialogRenderersteal key-window status on macOS, causing the parent window's title bar and traffic-light buttons to grey out as if the window were inactive. This happens becausefocusableWindowStateistruewhensetVisible(true)is called, making theJDialogthe macOS key window and deactivating the parent.Notice how with this PR the semaphore icons remain active:
Changes
focusableWindowStatetoggle technique used in IntelliJ'sAbstractPopup/DialogPopupWrapper: setfocusableWindowState = falseandisAutoRequestFocus = falsesynchronously beforeisVisible = true, then restorefocusableWindowState = trueviaSwingUtilities.invokeLater. The popup shows without becoming the key window, but can still accept focus on explicit interaction.AWTEventListenerkeyboard gate fromdialog.isActivetodialog.isVisible, soonKeyEvent/onPreviewKeyEventcallbacks fire without requiring the dialog to hold key-window status.Release notes
Bug fixes
JDialogRenderer.